Unity多人游戏联机功能Netcode的迁移与升级

众所周知，我们将UNet功能转移到维护模式，因为我们相信全新的联机游戏技术栈是更好的方法。自从宣布这项通知后，我们了解到许多开发者需要升级游戏最佳联机方法的指南。

开发者的选择取决于游戏的特定需求。正如下面流程图所示，开发者可以有很多选择，包括：继续使用现有的UNet功能，使用全新的DOTS-Netcode功能（包含高效的高级联网代码）和Unity Transport Package（底层联网技术栈）。

本文，我们综合多个关键问题，介绍如何对联网技术栈的选择做出重要决策。

用户规模

当我们谈论到联机游戏的用户规模，我们经常会提到一次会话或同时连接到一个服务器的最大玩家数量。

当尝试同时同步超过24名玩家时，点对点（P2P）拓扑通常会非常困难，因此为了支持25个及更多玩家的游戏会话，我们建议使用专用服务器DGS拓扑。

此外，即使在专用服务器DGS上，服务器运行时的性能和可扩展性也很重要，例如：FPS示例项目利用了Unity经典的“Headless”服务器运行时，经过我们的测试，该项目使用其示例联网代码可以同步多达80个联机的游戏客户端。

但是，相对于我们未来的DOTS服务器运行时，该运行时并不是那么高效，也没有很强的可扩展性，很难将服务器调整为支持超过80名玩家。

为了应对每个会话超过80个玩家数量，开发者需要成为新DOTS-Netcode和Unity Transport Package（UTP）的早期使用者，或者研究开发自己的技术栈。

另外一个需要注意的事项，调整过程也可以根据联网对象或AI的数量来衡量，例如：如果游戏世界需要同步500多个对象或AI，我们可能需要改为使用新的DOTS-Netcode和UTP，也可能考虑使用新的无状态物理功能确保实现稳定模拟效果。

作弊

下一个为游戏考虑的问题是作弊问题。游戏越流行，游戏客户端就越有可能被破解，产生不公平的游戏情况。即使游戏不是直接的玩家对抗PVP模式，也会遇到作弊行为。

游戏使用以下机制的情况下会产生作弊：

• 付费内容：限制访问内容，直到玩家购买通行证或物品。

• 排行榜或锦标赛：间接的竞争会给作弊带来动机。

• 声望或稀有物品：难以获得的低概率物品。

共享音乐会这类体验不会给人作弊的动机，通常对于开发来说比较安全。我们发现，许多游戏遇到的作弊问题比开发者所预想的还要严重。

当发生破解客户端和作弊行为，那么最好的选择就是使用“服务器权限”来完全阻止它。通过使用服务器权限功能，服务器代码会决定哪个玩家死亡，哪个玩家胜利，战利品是什么等信息，所以即使游戏客户端被破解，最糟糕的情况也不会影响其他玩家，因为最可能引起争议的数据会由服务器决定。

对比而言，在P2P网络拓扑中，游戏客户端有自身数据的管理权限，在这些情况下，开发者所能做的就是通过发送数据到云端来检测作弊行为，运行针对作弊行为的规则，然后尝试封禁作弊玩家。然而，一些游戏玩家非常聪明，喜欢对这类规则进行逆向工程来解决它们，所以开发者经常发现自己在做无用功。

在大多数情况下，DGS拓扑是最简单最高效的解决方案，可以确保实现带来营利的公平游戏。

延迟

现在我们要谈谈游戏中的“延迟容忍度”。开发者需要思考：如果游戏需要1秒时间从其他联机玩家获得更新数据，玩家体验会是什么样的？是否会有使玩家退出游戏的强烈“延迟感”？

这就是我们所说的“延迟容忍度”，即在游戏体验变得不再有乐趣且无法游玩前的最大可容忍延迟。

PC或主机平台的FPS游戏等快节奏游戏通常需要客户端之间的通信延迟在150ms以内，理想情况下大概50-100ms的范围或以下。在这些情况下，需要使用DGS拓扑，因为P2P Relay中继服务会加倍每个玩家的预期延迟，而且经常无法确保稳定在200ms以内的延迟。

一些节奏稍慢的游戏介于二者之间，可以支持P2P拓扑，例如：移动设备上的一些射击游戏可以容忍高达200-250ms的延迟，因为手指输入的有限精度要求游戏需要有较慢的节奏。在这些情况下，如果游戏的作弊可能性较低且玩家规模较小，使用UNet LLAPI和Photon或Steam等第三方中继服务就够了。

卡牌游戏在内的大多数游戏无法容忍超过1秒的延迟，这就是为什么我们的“UNet”（HLAPI+中继服务）解决方案会导致糟糕的玩家体验，具体取决于玩家和活动的中继数据中心的距离，所以该系统往往不是游戏的正确选择。

发布时间

如果你最后使用了DGS拓扑，我们需要知道游戏的预期发布时间，因为你的选择将根据可以使用的功能而变化。

下面是大致的发布时间情况：

• 目前：Unity Transport Package和Reliability已经提供预览版，它可以结合FPS示例项目中的示例代码，实现用于服务器授权游戏的较高等级联机代码。例如：客户端的预测功能和服务器的延迟补偿功能。

  由于Unity Transport仍处于预览阶段，如果现在需要比较稳定的表面层API，可以选择使用LLAPI。

• 2019年第三季度：预览版DOTS-Netcode将在今年秋季发布，提供服务器授权技术栈，包括：实体序列化、增量压缩、正向预测和插补功能。

  由于仍处于预览状态，直到该技术栈达到验证状态前，开发者会遇到较大的改动。

• 2020年春季或夏季：可用于正式制作的DOTS-Netcode。我们的目标是在2020年春季或夏季发布可用于正式制作的版本，DOTS-Netcode和UTP将变得足够稳定，而且拥有完善的功能。届时，开发者会得到稳定的表面层API、技术栈和更好的文档。

如果你计划在2019年第四季度之前发布游戏，你可以使用目前现有的产品。一些开发者已经使用了新版Unity Transport Package和Reliability，以及基于FPS示例项目的自用联机代码，所以该方法也可以使用。

如果这种方法难度太大，也可以使用其它现有解决方案，例如：Photon Bolt，它也适用于DGS游戏。请注意：我们没有验证过这些现有选择方案的结果质量。

如果计划在2020年第三季度之前发布游戏，你可以从今年秋季开始使用预览版DOTS-Netcode，但需要注意未来对API表面的重大改动。如果你的开发团队不介意这个问题，那么尽早使用是保证技术栈不会过时的最好方法。如果介意的话，那么就要考虑前面提到的其它选择。

如果打算在2020年第三季度之后发布游戏，我们建议使用全新的技术栈，新技术栈是2020年底后唯一得到完全支持的Unity联网功能技术栈。

需要注意，新联机代码对DOTS技术有一些严格的依赖，开发者至少需要了解如何使用经典游戏对象代码和新ECS代码开发混合二种模式的游戏。这些工作流程会不断改进，但早期使用者会比使用UNet联机代码的用户遇到更多易用性方面的挑战。

如何选择

如果打算现在为游戏制作原型，应该怎么做？

这个问题很难回答，具体取决于在上面流程图的结果。

• P2P拓扑：目前我们有UNet和Relay中继服务，UNet将在Unity 2019.4 LTS稳定支持版继续支持2年时间。Unity Relay中继服务会继续支持到2022年。如果这些选择适用于你的游戏，继续使用它们是比较安全的选择。 

• DGS拓扑：为了确保顺利过渡到未来DOTS-Netcode，最好现在开始使用预览版UTP和FPS示例项目的示例联机代码。虽然FPS联机代码不使用DOTS，但它是以ECS为基础构建的，是一个有效的良好开端。

  如果高效性和规模不是很重要，而且你希望马上使用成熟的API表面，你可以考虑使用Photon Bolt或Forge等其它第三方联机技术栈来制作游戏原型。

未来展望

希望大家耐心等待我们开发Unity的未来联机游戏功能。我们正在努力实现端到端的解决方案，以帮助你开发出具有高性能和高可扩展性的独特可靠的联机游戏。

后续我们将发布开发者日志，提供关于开发DOTS-Netcode、UTP、匹配功能等服务的最新进展，敬请关注 !

更多Unity新功能介绍，尽在Unity Connect平台(Connect.unity.com）。

下载Unity Connect APP，请点击此处。 观看部分Unity官方视频，请关注B站帐户：Unity官方。

推荐阅读

喜欢本文，请点击“在看”